SemanticBSDD
Improving the GraphQL, JSON and RDF Representations of buildingSmart Data Dictionary
Vladimir Alexiev, Mihail Radkov, Nataliya Keberle
Objective
- highlight the defects in the original GraphQL implementation of bSDD
- overview the refactored solution proposed by Ontotext
- overview the proposed improvements
bSDD GraphQL Schema: Voyager
bSDD GraphQL Schema: PlantUML
PlantUML is used with soml2puml convertor tool
![]()
Original GraphQL: Findings (1/3)
- reference entities
ReferenceDocument, Country, Unit, Language are disconnected from the rest of the schema
- relation entities have only an incoming link but no outgoing link
- many entities cannot be queried directly from the
Root
- no backward arrows to get from a lower-level entity back to its “parent” entity
- a number of parallel arrows. GraphQL schema can use parameters to distinguish between the different uses
Original GraphQL: Findings (2/3)
At the high level of detail:
Property and ClassificationProperty are very similar, but there’s no inheritance/relation between themPropertyValue and ClassificationPropertyValue are exactly the same, so can be reduced to one entity
Original GraphQL: Findings (3/3)
Even more details:
- mixture of singular/plural in property names
property/properties, relations, synonyms, countriesOfUse, relatedIfcPropertyNames, etc.
Refactored GraphQL: Improvements
- all entities are queryable directly from the
Root
- link deduplication
- each link is named the same as target entity
- navigation between entities is bidirectional, e.g.,
Classification hierarchy can be navigated both up and down (parentClassification, childClassification)
- a query can traverse a
Relation entity to get data about the related entity:
Classification.relation -> ClassificationRelation.related -> ClassificationProperty.relation -> PropertyRelation.related -> Property
- a single entity
PropertyValue is used by both Property and ClassificationProperty
- property names are in singular
Presentation
- uniform identification for the search
- uniform URI design
- equal data retrieved from different API
Conclusions and Future Work
Here are further ideas for improvement:
- improvement of bSDD ontology
- implement more radical data model refactoring to convert “strings” (countries, reference documents, etc.) into “things”
- link bSDD units of measure to QUDT ontology
- perform deeper data quality analysis using SHACL shapes generation and validation provided by Ontotext Platform Semantic Objects
- address and resolve more data quality issues, including
- seeking correlation between dimension vectors, units of measure and physical quantity,
- parsing out enumeration values from
Property/ClassificationProperty descriptions and creation of corresponding PropertyValue lists
- make more graph visualizations
- obtain more interesting statistics using SPARQL
